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(54) Improved quality of service control in a mobile telecommunications network 



(57) In UMTS or EDGE or a similar network, each 
new call specifies a required QoS on handover (a Seam- 
less Service Descriptor) and an acceptable level of deg- 
radation (Service Degradation Descriptor); a call is only 
accepted into a cell if the QoS requirements in the two 
descriptors can be met, and if the QoS requirement in 
the two descriptors of existing calls will not be unaccept- 
ably affected. 
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Description 

[0001] This invention relates to a method of improved quality of service control in a mobile telecommunications 
network, such as the Universal Mobile Telecommunications System (UMTS) or the Global Packet Radio Service 

5 (GPRS) Enhanced Data-rate GPRS Evolution (EDGE), and to apparatus for carrying out the method. 

[0002] Enhanced second generation and third generation of mobile systems will provide different services to end 
users, extending the scope of second generation mobile systems from simple voice telephony to complex data appli- 
cations, for example voice over IP, video conferencing over IP, web browsing, email, file transfer, etc. The use of circuit 
switched services for Real Time (RT) applications guarantees a high Quality of Service (QoS) but uses the system 

10 capacity in a consuming and wasteful manner. This is due to the fact that a dedicated link is maintained throughout 
the entire lifetime of a connection. On the other hand, packet switched services provide a flexible alternative for RT 
data traffic over a radio interface as set out by B. Jabbari, E.H. Dinan, W. Fuhrmann, in "Performance Analysis of a 
Multilink Packet Access for Next Generation Wireless Cellular Systems", PIMRC 1 998, in the sense that they use the 
system capacity more efficiently, allow for user idle time, and adopt a volume charging policy. Moreover packet switching 

is may be more appropriate in scarce resource environments such as that found at the radio interface in mobile commu- 
nications. This is since additional system capacity may be realized over the air interface by taking advantage of the 
statistical multiplexing gain inherent in packet switched systems. However maintaining the QoS comparable to that of 
circuit switched system for RT services is an interesting challenge. 

[0003] This invention addresses the problems centered on Admission Control of packet data flows with Quality of 
20 Service (QoS) requirements. Traditional packet transmission systems operate as queuing systems, where each packet 
is transmitted at any time. This results in a user perceived system behavior with a low Quality of Service, as the transport 
network does not maintain certain delay bounds on the data. Novel scheduling mechanisms overcome these limitations, 
by assigning guaranteed minimum bandwidth to individual flows. Provided that the offered data of one flow does not 
exceed this guaranteed rate within a given time interval, the user may assume no congestion related delay in such 
25 QoS scheduling systems. These assumptions only hold as long as the total offered load associated with QoS enriched 
flows is lower than the total output capacity of the shared link. Therefore it is necessary to have a system entity which 
controls the admission of new flows to the system. This entity is called Connection Admission Controller (CAC) and it 
decides on the admission of new flows. Traditional CAC Algorithms are not designed to handle flows in a highly dynamic 
environment as found in wireless transmission systems. The present invention specifically addresses these issues. 
30 [0004] Broadly speaking, it is possible to divide the types of service of third generation mobiles into two main classes: 
Real Time services (e.g., voice, video conferencing, etc.), and Non Real Time services (e.g., database applications, 
web browsing, email, etc.). The UMTS QoS Technical Report, ITU-R (source: Nokia), January 1 999 defined four distinct 
traffic classes , for Universal Mobile Telecommunication Systems (UMTS): 

35 • Real Time classes (Conversational and Streaming) 
• Non Real Time classes (Interactive and Background) 



Table 1 



40 


describes each one of these classes along with their characteristics: 




Class 

No 


Traffic Class 


Class Description 


Example 


Relevant QoS 
Requirements 




1 


Conversational 


• Preserves time relation 


-Voice over IP 


- Low jitter 


45 






between entities making up 
the stream 

• Conversational pattern 
based on human perception 

• Real-time 


- Video conferencing 


- Low delay 


SO 


2 


Streaming 


• Preserves time relation 
between entities making up 
the stream 

• Real-time 


-Real-time video 


- Low jitter 
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Table 1 (continued) 



describes each one of these classes along with their characteristics: 


Class 
No 


Traffic Class 


Class Description 


Example 


Relevant QoS 
Requirements 


3 


Interactive 


• Bounded response time 

• Preserves the payload 
content 


- Web browsing 

- Database retrieval 


- Round trip delay time 

- Low BER 


4 


Background 


• Preserves the payload 
content 


- Email 

- File transfer 


- Low BER 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



[0005] The traffic classes have QoS attributes associated with them and these attributes include the following facets: 

1 . The traffic characteristics specified in terms of bandwidth: 

• The peak rate (bit/sec), 

• The minimum acceptable rate (bit/sec), 

• The average rate (bit/sec), 

• The maximum burst size (the maximum number of consecutive bits sent at the peak rate.) 

2. The reliability requirements of the connection. These include: 

The Bit Error Rate (BER) or Frame Error Rate [FER], 

• The maximum loss ratio (the proportion of received packets to undelivered packets), 

3. The delay requirements including: 

• The maximum tolerated delay (ms), 

• The maximum tolerated jitter (ms) (the variation in delay). 

[0006] This top-level of traffic class classification can support many QoS decisions without the need to examine 
closely the set of QoS attributes. For example conversational traffic could get no backward error correction assigned 
exclusively based on its traffic class characterization. 

[0007] Each traffic class is characterized by a set of QoS requirements that needs to be satisfied in an end-to-end 
mode. That is, both the wireless and the fixed subsystems that make up a mobile environment (see figure 1) need to 
implement structures responsible for providing and maintaining the required QoS. 

[0008] Many QoS requirements such as guaranteed bandwidth can be achieved for individual data flows by appro- 
priate scheduling strategies. These systems make one major assumption, which is: The total offered traffic load to 
the scheduling system is lower than the output capacity. "Thus the amount of accepted load in the system has to be 
controlled and is critical for the successful implementation of QoS scheduling. For wireless systems there are two 
special problems. Mobility of users among different radio cells results in dynamic load patterns in individual cells, and 
changing radio propagation conditions result in varying capacity for individual links. Thus the amount of offered load 
(of already accepted calls) and the output capacity vary. Besides these techn ical problems there is usually the economic 
desire to achieve high network utilization. A conservative CAC will possibly reject more load than what might have 
been acceptable. 

[0009] It is an object of the invention to provide a method and apparatus which permits more efficient use of band- 
width, improvement of end to end service quality, and improvement of load balancing in the network. 
[0010] According to the invention, in a wireless mobile telecommunications network, a method of call acceptance in 
a telecommunications cell characterized by providing for a requesting call a quality of service descriptor specif ic to that 
call, and accepting that call only when the required quality of service can be provided and the required quality of service 
of existing calls will not be unacceptably affected. 

[0011] Also according to the invention, a wireless mobile telecommunications network comprising a core network, a 
plurality of base stations, and a plurality of mobile terminals, there also being a connection admission controller, a 
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policing unit and a scheduler, characterized in that there is also provided means to provide at least one quality of service 
descriptor specific to a requesting call, and in that the connection admission controller is arranged to accept the re- 
questing call only when the quality of service in the descriptor can be provided and the quality of service descriptors 
specific to existing calls will not be unacceptably affected. 
5 [001 2] The invention will now be described by way of example only with reference to the accompanying drawings in 
which:- 

Figure 1 illustrates schematically a UMTS network; 
Figure 2 illustrates Quality of Service architecture in the UMTS system; 
10 Figure 3 illustrates a Seamless Service Descriptor and Service Degradation Descriptor values; 

Figure 4 illustrates a sample loss profile; 

Figure 5 illustrates Quality of Service management structure components in the arrangement of the invention; 
Figure 6 illustrates a sample connection status table; 

Figure 7 illustrates the general structure of a connection admission controller 
15 Figure 8 illustrates the decisions made in a connection admission controller according to the invention; 

Figure 9 illustrates the interaction of a scheduler with standard Quality of Service management components, in 
addition to the inventive arrangement; 

Figure 1 0 illustrates the time intervals between RLCs and packets of the same connection. 

20 [0013] In Figure 1 , a mobile telecommunications network 10, specifically the UMTS, comprises a Mobile Terminal 
(MT) 12 which communicates over an air interface 13 with a Base Station (BS) 14 which has a fixed connection 16 to 
a fixed network subsystem 18, which may be either an IP (Internet Protocol) network or the PSTN (Public Switched 
Telephone Network). 

[0014] The QoS (Quality of Service) architecture can be represented as in Figure 2, as a functional decomposition; 
25 QoS can be treated as a series of "chained services" operating at different levels; such an approach is suggested in 

Technical Specification Group Services and System Aspects, QoS Concept version 1 .1 .0, 3GPP, 1999. 

[0015] In UMTS, Terminal Equipment (TE) 20 can be connected to an MT 12; the BS 14 forms part of a UTRAN 

(Universal Terrestrial Radio Access Network) 22 which is connected through an Edge node 24 and Core Network (CN) 

Gateway 26 to a further TE 28. 
30 [0016] The end to end QoS service 30 can be regarded as made up, at a first level, of a Local Bearer Service 32, 

between the TE 20 and MT 12; UMTS Bearer Services 34 between MT 12 and CN Gateway 26; and External Bearer 

Service 36 between CN Gateway 26 and TE 28. 

[0017] At a second level, the UMTS Bearer Services 34 are made up of Radio Bearer Services 40 between the MT 
12 and the Edge Node 24, and a CN Bearer Service 42 between the Edge Node 24 and the CN Gateway 26. At a third 
35 level the Radio Bearer Service 40 is made up of a Radio Service Bearer 50 between MT 1 2 and UTRAN 22, and lu 
Bearer Services 52 between UTRAN 22 and Edge Node 24. At this level, the CN Bearer Service 42 is a Backbone 
Bearer Service 54 

[0018] At a fourth level there is a UTRA (U... T... R... A...) FDD/TDD (F... D... T../T... D... D...) Service 60 between 
MT 12 and UTRAN 22, and a Physical Bearer Service QoS 62 between the UTRAN 22 and Edge Node 24. 

40 [0019] In this specification, most of the QoS terms used are based on Traffic Management Specification, Version 
4.0, The ATM Forum, Technical Committee, aftm-0056.000, April 1996; in addition the term "loss profile", a wireless- 
specific QoS parameter, is described by S Singh, "Quality of Service Guarantees in Mobile Computing, Computer 
Communications", Vol 19, pp 359-371, 1996. However, in contrast to QoS for ATM (Asynchronous Transfer Mode) 
systems, in the arrangement according to the invention, QoS maintenance is not only adaptive, but it is maintained 

45 throughout the lifetime of a connection. 

[0020] In the description of a specific embodiment of the invention which follows, the assumptions made are that:- 

1 . All QoS transmissions have to be embedded into a data flow. A data flow is a sequence of data packets from 
the same source to the same destination in the network, for which the user has certain QoS requirements. Each 

so radio bearer is related to a single data flow. Because multiple radio bearers might be established for a single user, 

multiple data flows could exist simultaneously that are related to a single user, too. In the following all data flows 
are handled separately. 

2. Each Connection Request (CR) contains QoS requirements. The QoS requirements contain three parts. The 
first part (A) is a top-level classification. If not explicitly given this classification can be derived from actuaJ values 

55 from B : e.g. from the delay requirements. The quantification of such conversion table is out of scope for this pro- 

posal. Part B contains basic traffic specifications in means of bandwidth, delay and reliability. The third part (C) is 
wireless specific and deals with the question of how to deal with the flow in case of network congestion situations, 
mostly due to link degradation. It is assumed that each CR is specified with the parameters for B and C. If these 
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are not explicitly notified in a CR, it is assumed that it is possible to assign appropriate values to the unspecified 
fields. 

3. The variable link is assumed to be part in a multi-hop packet routing architecture and to be the only bottleneck, 
where potentially congestion situations may occur. This is justified by the assumption that a fixed link backbone 

5 network with the same bandwidth capacity compared to a wireless network is relatively cheaper to build. Therefore 

in our expected application field the network operator will make sure during the network planning that enough 
(cheap) backbone capacity is available to support the relatively expensive wireless network. 

4. Because a rate conserving scheduling strategy is used in the scheduler, the scheduler guarantees the required 
data rates, as long as the scheduling system is not congested. This is the case as long as the total offered load 

10 is lower or equal than the available effective throughput within a given monitoring interval. 

[0021] According to the present invention, two novel service descriptors are required, both of which permit the de- 
scription by a user of a requested service in terms suited to the characteristics of a wireless interface. 
[0022] The first descriptor is a Seamless Service Descriptor (SDD) by which a user specifies the level of service 
'5 which the user requires during a handover from one telecommunications cell to another. For simplicity this may be 
exemplified by integer granularity on a scale of 1 to 5; an SSD value of 5 means the highest quality of seamless service, 
such as that required for video handover; for video a service of quality 4 may be tolerable but an SSD value of 3 or 
less would render a video service unwatchable. 

[0023] For a voice service, an SSD value of 3 will probably be acceptable, because the human brain is capable of 
20 interpolation to smooth out errors of transmission. 

[0024] For a service such as file transfer, when real time transfer is not essential, an SSD of 1 would be acceptable. 
[0025] Figure 4 illustrates the three examples just given. 

[0026] Naturally, a user will be required to pay more for the higher SSD levels. 

[0027] A second descriptor, a Service Degradation Descriptor (SDD) allows a user requesting a new link also to 
25 specify the level of service degradation, and the type of degradation, which a user is prepared to permit. On the integer 
scale of 1 to 5 the descriptor defines the level by which the user will tolerate degradation; for example, the voice user 
may not be prepared to tolerate any loss, so SDD = 5, see Figure 4. 

[0028] The SDD is based on a loss profile, such as that set out by S Singh," Quality of Service Guarantees in Mobile 
Computing, Computer Communications", Vol 19, pp 359-371 , 1996. 
30 [0029] Suppose there is resource deterioration, e.g. a decrease in the quality of the air interface so that radio link 
capacity is reduced. The question may be asked, should payload be preserved at the expense of jitter requirements? 
[0030] Figure 4 shows a typical loss profile for a connection and specifies that, as a first step, jitter may be increased 
from ten milliseconds to twenty milliseconds, then as a second step in degradation, BER (Bit Error Rate) may be 
increased from 10 5 to 10* 3 . 

35 [0031] Thus SDD specifies how, when a resource insufficiency occurs, the QoS requirements of that particular call 
may be degraded. 

[0032] A fourth element which is specified is the Policer Flag by which the user indicates how the system may react 
if that user exceeds his allocated bandwidth; the concept of a Policer Flag is known in ATM systems. 
[0033] The four elements Seamless Service Descriptor, Service Degradation Descriptor, Loss Profile and Policer 
40 Flag are all specified in a Connection Request (CR) which is issued for each application which is requesting a wireless 
link, in both the uplink and the downlink, and regardless of the transport scheme used, which may be TCP (Transport 
Control Protocol), UDP (User Data Protocol) etc. 

[0034] On the basis of the Connection Request, the network makes a decision whether to accept or reject the request, 
depending on whether sufficient capacity is available to provide the service : and on whether supplying the requested 
^5 service will affect current connections to an unacceptable degree, i.e. to go beyond the SSD and/or SDD descriptors 
of these current connections. 

[0035] Also, when a service to be handed over is not robust, such as a video service, a request may be made for 
bandwidth within the target cell; the SSD functionality allows an incoming, high value SSD service to "borrow" bandwidth 
from a lower value SSD service already within the cell, so that quality can be maintained on handover. 
50 [0036] The decision is made by a QoS management structure, the components of which are shown in Figure 5. The 
components are viewed as logical entities, that is, the location is not indicated. The structure may be located in the 
MT 12, in a BS 14, or in both. 

[0037] The Connection Request CRi is supplied to a Connection Admission Controller (CAC) 70 which accepts or 
rejects the request, as set out above. For an accepted request, the CAC 70 generates a "create flow queue" message 
55 72, and a queue 74 of variable size is set up in the network layer for each CRi. Each queue comprises a variable size 
leaky bucket VBi with variable flow rate Fi. 

[0038] The output Oi of the bucket is monitored by the policer 76. Subsequently, as illustrated at 74', the RLC (Radio 
Link Control) protocol is initialized, as indicated at 78, and RLC blocks are passed to a scheduler 80 which also receives 
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input from a Radio Resource Manager (RRM) 82. The scheduler 80 serves each flow queue depending on its QoS 
requirements, setting up Transport Frames (TF) 84. 

[0039] Referring again to the queue 74, flows with BEC (B... E... C...)find that their ARQ (Automatic Repeat Requests) 
is set up and this is used for retransmission of lost or erroneous blocks. (The ARQ process for real time traffic classes 
5 will, in general, be void). 

[0040] The components comprising the QoS management structure are the CAC 70, the policer 76 and the scheduler 

80. 

[0041] Considering now the CAC 70, the basic principle of a CAC is to collect a certain number of Connection Re : 
quests (CRi) from flow i, i=1..n, where n constitutes the total number of already accepted and living flows. A flow is 

10 alive until the network or the user has terminated an established flow. 

[0042] A CR contains a set of QoS requirements, which builds the basis for the CAC algorithm to decide how much 
system resources this flow will potentially require. The CAC decision upon acceptance is thus driven by the question, 
if system resources will be sufficient to satisfy all existing plus the newly considered flow. Conservative CAC algorithms 
will do so if the probability of this decision is 1 00% proof. To increase link utilization many approaches aim for a CAC 

is behavior which achieves probabilistic guarantees, such as guarantees which hold for 55 minutes during an operating 
hour. These schemes are also referred to as over- reservation schemes. Given that the inventive usage of the parameter 
Loss Profile and the novel parameter SDD are probabilistic metrics, it is assumed that over-reservation is used and/ 
or temporarily accepted during operation. 

[0043] From a service provider point of view, the main goal of the CAC module is to admit a maximum number of 
20 CRs, and, at the same time, maintain the QoS requirements of existing connections. That is, the CAC module should 
avoid congestion in advance. In addition to this, independent from its actual implementation, the final output of the 
CAC module must be a Boolean value indicating whether the CR should be admitted or not. 

[0044] The CAC module receives a Connection Request (CR) from an application, network measures (multipath, 
path loss, and interference) from the Radio Resource Manager (RRM), and the traffic characteristics along with the 
25 QoS requirements of all existing connections from the serving Base Station. It then decides, based on the previous 
information, whetherthe CR can be accepted or not. The CR can be originated either from a new call orfrom a handoff. 
The CAC module should prioritize handoff CRs over new call CRs because, in general, interrupting a service in an 
active connection is more annoying to users than rejecting a new call. 

[0045] Besides local capacity estimates, CAC for wireless traditionally focuses on resource reservation for hand-off 
30 calls, which can lead to both extensive signaling overhead between base stations and low link utilization due to pes- 
simistic admission strategies. The Connection Admission Controller of the invention is not based on intercell resource 
reservation to guarantee a seamless service. Rather it uses the two new QoS parameters that are introduced (the SDD 
and the SSD) to either accept or reject an incoming request. In this model, each BS needs to maintain a table (a 
Connection Status Table) containing the connection identifier, SDD, SSD, and the total virtual bandwidth used by each 
35 connections within the current cell. Figure 6 shows an example of a Connection Status Table. 

[0046] The general structure of the CAC 70 is shown in Figure 7. It has two main parts, a Connection Impact Evaluator 
(CIE) 86 and a Boolean Decision Maker (BDM) 88. 
[0047] The CIE: takes as input the following parameters: 

40 • The actual Connection Request, 

• The available system resources (bandwidth and memory), of both the current cell and the neighbonng cells, form 

the RRM, 

• The Connection Status Tables, of both the current cell and the neighboring cells. 

45 [0048] Obviously, a protocol for exchanging information on existing connections between neighbor BSs at regular 
intervals needs to be specified. 

[0049] The CIE then outputs a set of probabilistic values predicting the impact of admitting the requesting connection 
on all existing active connections in the current and neighboring cells. Those probabilities are divided into two catego- 



50 



nes: 



The probability values of blocking n other active connections P B (n) in the current and neighboring cells. For ex- 
ample, a P B (1) = 0.3 means that there is a probability of 0.3 of blocking one active connection. 
• The probability of degrading the QoS of n other active connections in neighboring cells: 

55 • Probability of exceeding the delay requirement P d (n) 

• Probability of exceeding the jitter requirement Pj(n) 

• Probability of exceeding the BER requirement P b (n) 

• Probability of exceeding the loss requirement P,(n) 
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[0050] The BDM is the module that decides whether or not the CR is to be accepted. It is regulated by the probabilities 
issued from the CIE and a set of congestion metrics (the number of connection blocking N 1f the number of QoS deg- 
radation due to congestion N 2 , and the length of queues and buffers at the edge of the network N 3 .) One of the goals 
that the BDM needs to achieve is that its blocking and service degradation probabilities should be less than the natural 
5 blocking and degradation probabilities if no CAC is implemented. 

[0051] Figure 8 shows in detail the decisions made by the CAC 70. 

[0052] The input from the RM 82 and the other connections into the CIE 86 can be regarded as taking into account 
the Radio Bearer Services 40 and 50 in Figure 2, and the Link Congestion metric inputs can be regarded as taking 
into account the lu Bearer Services 52, the Backbone Bearer Service 54 and the CN Bearer Service 42 in Figure 2. 
10 Thus the whole breadth of the UMTS Bearer Service 34 is covered and in effect the end-to-end service 30 can be 
improved. 

[0053] On receipt of a call request CR, and with input from the RRM 82, in step 100 the decision is "are system 
resources available?". If yes, connect; if no, the SDD is checked in step 102; in step 104 the decision is made whether 
accepting the new CR would degrade other connections; if yes, ie if the existing connections are prepared to accept 

15 degradation to allow the new call, then connect. If no, in step 106 the loss profile of the CR is checked. In step 108, if 
this CR can be served according to its loss profile, connect; if not, the SSD is checked in step 110. In step 112, if it 
would block other connections to accept this CR, but the other connections can be stopped and restarted without III 
effect, ie if we can "steal" bandwidth, then the CR is accepted; if not, the CR is rejected and the application is informed 
that the network is unable to accept the request. 

20 [0054] On acceptance, a new flow queue is created and a connection identifier is assigned to all packets which are 
issued for that connection. 

[0055] As an example, a CR can be rejected, even if system resources are available, if the CIE 86 outputs a high 
blocking probability value, and the congestion metrics indicate an increasing number of blocked connections. 
[0056] Although a specific CAC entity has been described, a distributed version would beneficially spread the required 

25 computational power to several units, and lower the response time to a request. 

[0057] Consider now the policer 76 in Figure 5. In a network where different connections are competing for resources, 
a policing mechanism is suited to monitor traffic sources, if they behave in compliance with their own specifications. 
Furthermore a policer can interact and alter the offered load in order to make it flow compliant. In the present approach 
both actions are foreseen, while it is left to the user to select the operation mode. 

30 [0058] In this application, a simple policer operating at the data link layer of the BS is described. Obviously its location 
can also be shifted e.g. to the gateway entry of the core network. The policer monitors and enforces the traffic char- 
acteristics (peak rate, average rate, and burstiness) of a given flow queue based on a token-based leaky bucket algo- 
rithm. 

[0059] The peak rate of a flow is controlled by simply comparing the bit inter-arrival time with the inverse of the peak 
35 rate specified when the Connection Request was issued. The bit inter-arrival time must be less than the inverse of the 
peak rate for a conforming traffic. The average rate is enforced by setting the leaky bucket's token arrival rate to the 
agreed upon average rate. Note that "bit inter-arrival time" underlines that this is a volume dependent view and not 
done on a per packet basis. 

[0060] It can easily be shown that the burstiness can be controlled by adjusting the size of the leaky bucket. Burstiness 
40 is the maximum number of consecutive bits sent at the peak rate. The size of the token-based leaky bucket can be set 
in order to enforce the agreed burstiness: 
For a given traffic, the size of the leaky bucket should be set to: 



45 o fi Average Rate 

Sue =11 

^ Peak Rate 

provided that the Average Rate is strictly smaller than the Peak Rate. If the average rate is equal to the peak 
50 rate, then the burstiness is not defined. This makes sense since the definition of the burstiness is the maximum number 
of consecutive bits that can be sent at the Peak rate. 

[0061] Concerning the action to be taken by the policer with regard to connections not conforming to the agreed 
upon traffic characteristics, the policer examines the "Policer Flag" specified within the connection request. If the Policer 
Flag is ON, this means that the user is willing to pay extra charges (according to a billing policy defined by the service 
55 provider) for the transmission of non-conforming packets (provided enough system resources are available). If, how- 
ever, the Policer Flag is OFF, then the policer discards all non-conforming packets. 

[0062] On connection of a call, the network guarantees the user requirements as to delay, jitter and a bandwidth. 
The ease with which these requirements can be met depends on external conditions, primarily the air interface. The 



x Burstiness ( 1 ) 
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network may need to vary the proportion of data and protection if the interface deteriorates, i.e. it may need to vary 
the bandwidth. Similarly, deterioration of the air interface may cause a concertina effect, ie the proportion of raw data 
within a packet is decreased. 

[0063] It is the scheduler 80 (see Figure 5) which takes these factors into account. 

5 [0064] Considering first the arrangements in the prior art, for the application to UMTS a scheduler is responsible for 
the order of transmission of different RLC blocks within a transport frame. It is configured from Radio Resource Manager 
(RRM), located at the BS, with a set of Transport Format Combinations (TFC) which have been assigned during re- 
source allocation to the flow. Each Transport Format (TF) is characterized by at least a coding scheme and its corre- 
sponding number of bits that can be transmitted. The scheduler chooses one TF that would optimize the link utilization 

w and. at the same time, satisfy the QoS requirements of all flow queues belonging to different traffic classes. 

[0065] Different scheduling schemes may apply, depending on the traffic direction. For wireless systems, as e.g. 
UMTS, there is one scheduling method on the dedicated shared channel, where the MS transmits in the uplink direction 
over the air interface whenever it has data to send. In GPRS the MS has to perform an access procedure and its UL 
data is actively scheduled and signalled to the MS from the central BS. In the downlink for all known system the BS 

15 synchronises all RLC blocks and sends data at regular intervals. 

[0066] In the present invention , the scheduler is applied in a rate conserving manner to implement the QoS bandwidth 
requirements, that is, the scheduler monitors and grants access to the shared link to the individual data flows in pro- 
portion to their specified bandwidth requirements. The actual scheduling scheme is not relevant. 
[0067] Figure 9 illustrates the interaction with standard QoS management components. The inventive arrangement 

20 with a variable queue 81 , a CR 83 and an ARQ 85 interacts with the scheduler 80. The scheduler 80 also interacts 
with standard queues j and k each having a Connection Request CRj, CRk. The output of the scheduler is a stream 
of RLC blocks 84, which may be PDUs or ARQs. 

[0068] For the scheduler to meet all existing flow queues (the performance requirements of the scheduler), the QoS 
requirements are: 

25 

• RT Traffic Classes: characterized by the following QoS requirements (relevant to the scheduler): 

• The maximum tolerable delay: Dmax, which is the maximum tolerable time it takes for a Network Layer Packet 
to be transmitted, 

30 • The maximum tolerable jitter: Jmax, which is the maximum tolerable variation in packet delay, and 

• The Packet Loss Ratio. 

[0069] Assumption 3 above focuses on delay issues for the particular scheduling system. It is assumed that there 
is no significant additional delay caused by the backbone network. Of course this influence may be estimated or signaled 
35 by some future QoS mechanism. If the influence of the backbone is available it will be subtracted from the flow require- 
ments first and the new constraints will become tighter for our scheduler. 

[0070] In Figure 10, let t inter be the time interval between two consecutive RLC transmissions 84 belonging to the 
same packet, and let T inter be the time interval between the last RLC of packet i and the first RLC of packet /+ 1 for the 
same connection. 

40 [0071 ] Also let D, be the packet delay for a given packet #. So, D, = T inter + £^ ter That is, in order to meet the delay 
requirement for a RT flow, the scheduler 80 must maintain the following inequality true: T inter + Z^ /er <Dmax. 
[0072] In addition to this, the scheduler 80 must also meet the jitter requirement for a RTflow. That is, - D f <Jmax. 
Note that D i+1 - Di can be negative, assuming that a given packet can be buffered at the destination to maintain a small 
delay variation. Consequently, the scheduler needs to adjust the values of t inter in order to meet both delay and jitter 

45 requirements. 

[0073] The loss ratio specified in the flow queue specifies the fraction of packets that can be delayed over the max- 
imum tolerable delay (considered lost.) 

♦ NRT Traffic Classes. Characterized by the following QoS requirements (relevant to the scheduler): 

50 

Maximum tolerable delay. Dmax (class #3 only), and 
Bit Error Rate: BER (classes ff3 and #4) 

[0074] By adopting the previous terminology, the scheduler needs to maintain the following inequality true for traffic 
55 class #3 flows: T^ /er + £' /nter <Dmax. 

[0075] In order to meet the BER requirement, the scheduler needs to choose a TF having a coding scheme that 
maintains the required BER. Note that lost packets for NRT classes are retransmitted using an ARQ process, making 
the PHY-link BER requirements an optimisation process, not covered here. 
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[0076] The scheduler 80 may find itself in congestion situations due to several reasons. The system may be over- 
loaded by aggressive CAC strategies or unexpected Handoffs into the cell under consideration. Also the estimated 
transmission capacity might be overestimated. This can happen when links degrade in quality and more systems 
resources are required to achieve the former effective throughput. 
[0077] Several stages of load balancing in case of a congestion situation are proposed: 

Firstly marked packets by the policer from flows with non-flow compliant behaviour are discarded. Then if the system 
resources are still limited, the scheduler initiates a RRM procedure to alter some flow requirements. The exact proce- 
dure is out of scope here. Basically it will base its decision on the loss profile of individual flows and find a flow that is 
suited to be degraded. This degraded parameters will then be notified back to the scheduler. This is repeated until the 
scheduler find itself in not congested anymore. When the situation is stable the former degraded flows are restored in 
a reverse manner. If possible this mechanism also informs (via a control plane) the corresponding application of the 
changes in QoS terms. 

[0078] In the invention the inherent characteristics of the air interface of a mobile wireless packet switched transmis- 
sion system are taken into account when considering the QoS for traffic flows across the air interface. This is since 
the SSD, SDD and LP together realistically reflect the achievable QoS for a wireless service. There are specifically 
two occasions where the achievable QoS temporarily alters. During normal operation with no handover scenarios the 
available capacity may change substantially due to altered radio conditions for individual links. This reduced link ca- 
pacity may yield scheduling congestion situations. For handover/handoff scenarios there might be additional load, 
which cannot be easily rejected by Admission Control mechanisms, as it is generally not desired to cut of existing flows. 
These additional load may also cause congestion situations. In the case of Handoffs this amounts to an improvement 
on existing solutions because existing solutions reserve bandwidth in neighboring cells in order that handovers/handoff 
are smooth for RT services. This method while robust reduces the capacity of the system moreover in Third Generation 
(3G) systems there is the added complication of having ongoing variable bandwidth demands at the time of handover. 
Under this circumstance the overhead of reserving bandwidth to guarantee the QoS at handover becomes costly in 
terms of cell capacity. Therefore having a method which takes into account the demands of new connections in a highly 
flexible manner would be highly desirable since cell capacity would be used in a more effective manner. Moreover the 
invention can be applied in a general sense to packet switched services since the policing and scheduling elements 
take care of the traffic behavior either side of a handover/hand -off. Finally the invention allows for more aggressive 
over- reservation of system resources hence a higher network utilization, because it is possible to overcome potential 
congestion situations in such manner, that the affected services are degraded in such way that this is still acceptable 
for the users. 

[0079] While the invention has been described with reference to the UMTS, it is applicable to any enhanced second 
generation or third generation mobile telecommunications system. 



1 . In a wireless mobile telecommunications network, a method of call acceptance in a telecommunications cell char- 
acterized by providing for each requesting call a quality of service descriptor specific to that call, and accepting 
that call only when the required quality of service can be provided and also the required qualities of service of 
existing calls will not be unacceptably affected. 

2. A method according to Claim 1 in which the quality of service descriptor comprises a service degradation descriptor 
which specifies a preferred type of degradation of quality of service. 

3. A method according to Claim 2 in which the service degradation descriptor specifies acceptable decreases in jitter 
and bit error rate, and the order in which such decreases are to be applied. 

4. A method according to any preceding claim in which there is also provided a second quality of service descriptor 
specific to each requesting call comprising a seamless service descriptor which specifies a preferred quality of 
service during a handover from one telecommunications cell to another 

5. A method according to Claim 4 in which the seamless service descriptor specifies quality of service on handover 
by specifying bandwidth requirements. 

6. A wireless mobile telecommunications network comprising a core network, a plurality of base stations (1 4) and a 
plurality of mobile terminals (12), there being a connection admission controller (70), a policing unit (70) and a 
scheduler (80), characterized in that there is also provided means to specify a at least one quality of service 
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descriptor specific to a requesting call, and in that the connection admission controller (70) is arranged to accept 
the requesting call only when the quality of service in the descriptor can be provided, and the qualities of service 
descriptors specific to existing calls will not be unacceptabty affected. 

5 7. A network according to Claim 6 in which the connection admission controller (70) comprises a Boolean decision 
maker (88) and a connection impact evaluator (86) arranged to assess the impact of accepting a requesting call 
into an active telecommunications cell. 
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